BTOP

btop is an interactive, real-time system monitor for Linux that visualizes CPU, memory, swap, disk I/O, network activity, and per-process resource usage. It is a practical daily tool for WordPress VPS operations because it makes resource saturation patterns easier to spot than text-only monitors, especially during plugin updates, traffic spikes, backups, and database-heavy workloads.

Background and history

Real-time monitoring on Linux historically relied on tools like top and later htop. As servers and workloads became more complex, operators needed clearer, faster-to-interpret visualizations for I/O and network bottlenecks. btop emerged as a modern terminal UI monitor focused on rich charts, low overhead, and interactive process inspection while remaining usable directly over SSH.

Adoption and where it’s commonly used

btop is commonly used on:

• VPS and cloud Linux servers (Ubuntu/Debian, RHEL-based, Alpine)
• Web stacks (WordPress with OpenLiteSpeed/Apache/Nginx + PHP-FPM/LSAPI)
• Database and cache hosts (MariaDB/MySQL, Redis)
• Incident response and tuning sessions (CPU spikes, swap pressure, I/O contention, bot traffic)

Maintained by

• Maintained by the btop project community.

Best when to use

• You want fast visual correlation across CPU, memory, disk, and network during incidents.
• You frequently investigate whether slowdowns are CPU-bound, I/O-bound, or network-driven.
• You need per-process sorting plus system-level graphs in a single terminal UI.
• You want a production-friendly monitor with low overhead.

Not suitable when

• You need long-term historical analysis (use a metrics stack and dashboards).
• You need automation-friendly output for scripts (use ps, pidstat, sar, iostat).
• You need deep application profiling (use slow query logs, APM, tracing, request logs).

Compatibility notes

• btop is available on many distributions, but package versions vary by repo.

• Some features (temperature, frequency) depend on kernel support and permissions.

• In containers, btop typically shows only container-visible processes and stats.

• Process names vary by stack:

  • OpenLiteSpeed often uses lsphp
  • PHP-FPM may appear as php-fpm, php-fpm8.x, and pool workers
  • MariaDB may appear as mariadbd and MySQL as mysqld

Installation

Debian/Ubuntu

sudo apt update
sudo apt install btop

RHEL/CentOS Stream/Rocky/AlmaLinux/Fedora

sudo dnf install btop

Alpine

sudo apk add btop

Snap (when you need a newer build)

sudo snap install btop

Package version differences

Repository packages may lag behind upstream. If you rely on a specific btop feature, verify the installed version with btop --version and prefer the distribution-supported upgrade path used in your environment.

Launch and exit

btop

Exit with q.

UI layout and what to watch

btop is typically organized into panels:

Panel	What it shows	What it tells you in WordPress operations
	--	-
CPU	Per-core usage, load, frequency (and sometimes temperature)	Plugin spikes, PHP worker storms, DB query spikes
Memory	RAM usage breakdown, cache/buffers, swap	Memory pressure, mis-sized DB/Redis/PHP limits
Disks	Per-disk throughput, utilization, latency	Backup writes, DB flush bursts, slow storage
Network	Throughput, connections	Bot spikes, brute-force bursts, CDN bypass, DDoS patterns
Processes	Sortable per-process CPU/MEM/I/O	Which service is the culprit and whether it’s one PID or many

Interpret “free memory” correctly

Linux aggressively uses RAM for caching. Low “free” RAM is not automatically bad. The main risk signals are sustained swap growth, OOM events, and services being killed or timing out under pressure.

Daily WordPress metrics and how to interpret them

CPU: PHP workers, DB contention, cron storms

Look for these process patterns:

• lsphp (OpenLiteSpeed) or php-fpm workers climbing and staying high
• mariadbd/mysqld rising with sustained CPU
• Compression/backup processes (tar, gzip, zip) stealing CPU

Operational interpretation:

• One process pegged on one core: stuck loop, single expensive query, or runaway job
• Many PHP workers moderately high: request load, uncached endpoints, bot traffic, or expensive plugin behavior

Memory: PHP per-request costs, DB buffer sizing, Redis growth

Focus on:

• Per-process memory (RES-like behavior in the process list)
• Total memory pressure trends (memory panel)
• Swap usage trend (memory panel)

Red flags:

• Swap steadily increasing over minutes
• Memory usage rising without stabilizing (leak-like pattern)
• DB/Redis configured to consume more than the host can safely support

Swap: early warning for performance collapse

Swap should typically remain low on WordPress VPS:

• Small bursts can happen
• Sustained swap usage usually correlates with slower TTFB and admin latency

If swap grows:

• Expect PHP and DB response times to degrade
• Consider reducing memory allocations (DB buffers, Redis maxmemory, PHP worker count) or upgrading RAM

Disk I/O: database flush, backups, and “high load but low CPU”

I/O bottlenecks often present as:

• High disk utilization/latency graphs
• Load average rising while CPU is not fully saturated
• Many tasks waiting on I/O (not directly shown by btop, but correlated via disk latency)

Common causes:

• MariaDB flushing and checkpointing
• Backup jobs writing large archives
• Slow storage tiers or full disks

Network: bots, brute force, and connection storms

Network spikes plus rising PHP workers often indicates:

• Bot bursts hitting uncached endpoints
• Brute-force attempts against wp-login or XML-RPC
• CDN bypass (origin exposed directly)

Network spikes plus low CPU but high connections suggests:

• SYN floods or connection management overhead at the edge
• Misconfigured firewall rules or missing rate limits

Core navigation controls

Common btop controls (may vary slightly by version/config):

Action	Key
Switch focus between panels	Tab
Open menu / settings	Esc or m
Search process	/
Sort processes	s
Kill/terminate a process	k
Quit	q

Key mappings can differ

If keys behave differently, open the menu/settings and review configured keybinds for your installed version.

Practical workflows you can run daily

1) Triage a slow WordPress site in under a minute

In btop:

1. Check CPU panel: is CPU saturated or just spiking?
2. Check memory panel: is swap increasing?
3. Check disk panel: is disk latency high?
4. Check network panel: is traffic or connections abnormal?
5. Go to Processes panel: sort by CPU and identify top offenders

Safe follow-up commands (read-only first):

# Identify listening services and active sockets (read-only)
ss -tulpen
ss -tan | head

# Confirm service status
systemctl status lsws 2>/dev/null || true
systemctl status nginx 2>/dev/null || true
systemctl status apache2 2>/dev/null || true
systemctl status php*-fpm 2>/dev/null || true
systemctl status mariadb 2>/dev/null || systemctl status mysql 2>/dev/null || true
systemctl status redis 2>/dev/null || systemctl status redis-server 2>/dev/null || true

2) Investigate a plugin update spike

Run the update in one session and btop in another.

In btop, watch:

• CPU distribution across cores
• PHP worker count and whether they persist after the update
• Disk writes (unpacking, file operations)
• DB spikes (schema changes, options updates)

If CPU stays high after the update:

• Sort processes by CPU and identify the exact service/PID group.
• If it is PHP workers, check access logs and application logs before intervening.

3) Confirm whether the bottleneck is CPU, RAM, I/O, or network

Use this pattern:

Symptom	Likely bottleneck	What you’ll often see in btop
--		-
CPU near saturation, load rising	CPU-bound	CPU panels high; process list dominated by PHP/DB
Swap rising, memory near limit	RAM-bound	Swap increasing; many workers; random slowdowns
Disk latency/utilization high	I/O-bound	Disk graphs high; CPU may be moderate; load rises
Network throughput/conn spikes	Network/bot-driven	Network graphs high; PHP workers spawn bursts

4) Detect wp-cron storms

In Processes:

• Search (/) for wp-cron
• Also check for repeated short-lived PHP worker bursts

Common mitigation pattern:

• Disable pseudo-cron and run a controlled OS cron schedule appropriate for the site.

5) Validate Redis behavior after tuning

In btop:

• Watch Redis memory usage stabilize within expected bounds
• Watch network utilization (cache hits can change traffic patterns)
• Confirm that swap is not trending upward due to Redis growth

Sorting and process inspection

Sort by CPU

• Focus the Processes panel
• Sort (s) by CPU

Use this to:

• Identify hot PHP workers (lsphp, php-fpm)
• Identify database spikes (mariadbd, mysqld)
• Identify batch jobs competing with web traffic (tar, gzip, backups)

Sort by memory

• Sort (s) by memory

Use this to:

• Identify memory pressure sources (DB buffers, Redis, excessive PHP worker footprint)

Use search to reduce noise

Search (/) for common WordPress stack processes:

• lsphp
• php-fpm
• mariadbd / mysqld
• redis
• cron

Safe process intervention

Renice before you kill

If a non-critical batch job is competing with production traffic, reduce its priority first (preferably using dedicated commands rather than guessing inside the UI).

Read-only verify priority:

ps -o pid,ni,pri,comm -p <PID>

Terminate a process carefully

Use the process kill function (k) only after verifying what it is.

Recommended escalation:

1. Graceful termination (SIGTERM)
2. Force kill (SIGKILL) only if necessary

High-risk targets

Avoid terminating critical services from the UI unless you have a clear recovery plan: sshd, mariadbd/mysqld, lsws/nginx/apache2, and PHP-FPM master processes. Prefer controlled service actions with systemctl during maintenance windows.

Persistent monitoring

Running btop detached is usually not necessary and can complicate operational clarity because terminal UIs are interactive. Prefer using:

• A terminal multiplexer (such as tmux) to keep btop running
• A proper metrics stack for long-running monitoring

If you must background it:

nohup btop >/dev/null 2>&1 &

Stop it:

pkill btop

Operational clarity

Backgrounding interactive monitors can make it harder to know what is running and why. Prefer tmux for persistent sessions, or use metrics and alerts for continuous monitoring.

Troubleshooting matrix

Symptom	Likely diagnosis	Action
--		-
High CPU	PHP worker storm, bad plugin loop, heavy DB queries	Identify top process, check logs, tune caching, mitigate wp-cron
High disk I/O	DB flush bursts, backups, log growth	Reschedule backups, tune DB, verify disk health and free space
Swap usage	RAM pressure from DB/Redis/PHP worker footprint	Reduce allocations, tune worker counts, add RAM if needed
Network flooding	Bots/brute force, origin exposed	Enable rate limits, tighten firewall, use WAF/CDN controls
Load high but CPU moderate	I/O wait or storage bottleneck	Correlate with disk latency; investigate I/O tools and logs

Go-live checklist for daily operations

Check	Target
--	-
Load average vs core count	Sustained load at or below core count
Memory usage	Stable with headroom
Swap	Minimal and not trending upward
PHP workers	Stable, not continuously saturated
Database	No sustained high CPU or I/O spikes without cause
Redis	Memory bounded and stable
Network	No unexplained spikes or connection storms

Quick lab: observe controlled load

Run a controlled test (only on non-production or during a maintenance window). Start btop, then generate load from a trusted host.

Example with ab:

ab -n 2000 -c 50 https://yourdomain.com/

In btop, observe:

• CPU distribution across cores
• PHP worker behavior and persistence after the test
• Disk I/O and latency during peak
• Network throughput and connections

Load testing risk

Synthetic load can degrade service and trigger security controls. Use maintenance windows, non-production environments, or reduced concurrency that matches your risk tolerance.

Cheat sheet

Task	Key / Command
--	--	--
Launch	btop
Quit	q
Switch panel	Tab
Search process	/
Sort processes	s
Kill/terminate	k
Check version	btop --version
Confirm sockets	ss -tulpen
Top CPU consumers	`ps aux --sort=-%cpu	head`
Top memory consumers	`ps aux --sort=-%mem	head`